I have noticed more and more mods lately that are uploaded to PES or other sites that include the common modding mistake of making unintended changes to standard MW references. Although these mods may have excellent content otherwise, they have the potential to set up mod-breaking or awkward conditions for other mods as indicated in the examples below:

Example 1:
Mod A has an apparent change to the standard MW Light Reference “light_dwe_bulb00” (which has a radius of 600 and a pale yellow color in the standard). If any changes were not intended to occur to this light by the modder of Mod A, but an inadvertent change occurred for the reasons later below, it will change this light to the MW standard for any mods loaded previous to it that had other intended changes to that light – i.e. Mod B, which has an earlier save date than Mod A and thus loads first, changes all the dwemer lights to a smaller radius and darker color to provide a darker, more sinister effect in dwemer ruins as the primary premise of Mod B. Using both Mod A and B together now will lose that change that Mod B intentionally made for any of the light_dwe_bulb00 references because it will be overridden to the MW default by Mod A.

Example 2:
Mod A also has an apparent change to the standard MW Static Reference “in_nord_fireplace_01”. If any changes were not intended to occur to this fireplace by the modder of Mod A, but an inadvertent change occurred for the reasons later below, it will change this fireplace to the MW standard for any mods loaded previous to it that had other intended changes to that fireplace – i.e. Mod C, which has an earlier save date than Mod A and thus loads first, changes all the nord fireplaces to a smaller size (90% of standard) in an effort to lower the mantle level since they considered the fireplace too big in relation to the size of other fireplaces in the game. Mod C took great care to insure that all items placed on the mantles of Nord fireplaces already placed in the game were adjusted to look correctly on the mantle. Using both Mod A and C together now will cause those items placed on the mantle of Nord fireplaces in the standard game to appear to be “bleeding” into the mantle because it will be overridden to the MW default by Mod A. (Conversely if the Mod C changes to the fireplace were to make it a larger size, the items placed on the mantle in this situation would appear to be “floating” above the mantle.)

Example 3:
Mod A also has an apparent change to the standard MW Activator Reference “a_siltstrider” (which does not have a local script attached in the standard). If any changes were not intended to occur to this activator by the modder of Mod A, but an inadvertent change occurred for the reasons later below, it will change this activator to the MW standard (without script) for any mods loaded previous to it that had other intended changes to that activator – i.e. Mod D, which has an earlier save date than Mod A and thus loads first, changes all the siltstriders through an attached local script to now have movement or perform a certain action. Using both Mod A and D together now will cause the siltstriders to lose this movement/action that was the primary premise of Mod D because it will be overridden to the MW default by Mod A. This could also break Mod D and the game if something in those local scripts were required for Mod D to function properly without errors.

Many other examples could be given but the three above are provided to give insight into how not cleaning up these inadvertent reference changes can cause frustration and apparent errors that may be attributed to Mod B, C and/or D when in fact the errors are because of Mod A. This can be quite confusing to the mod user since they may have been playing Mod A for some time without apparent problems and now that they have decided to use Mod B/C/D, they don't seem to work as advertised even though it is not Mod B/C/D's fault in this case. Those inadvertent changes in Mod A have the potential to affect hundreds of other mods adversely.

How do these inadvertent changes to MW Standard occur?
A common MW modding mistake that causes changes such as this to appear is to select the SAVE button on a standard MW reference after the modder has made changes below the “Reference Data” section line for items they double-clicked in the Render Window of the CS, OR if they selected the SAVE button for any standard MW item in the Object Window. The accepted practice is to create new IDs and not change the standard MW references UNLESS the changes were intended to affect all occurrences of that reference ID in the standard game as a primary premise of the new mod. For items you are only changing the reference data, after you make that reference data change select the close window button (little X in upper rightmost corner of the reference window for the object) INSTEAD OF selecting the SAVE button.

How can I find these inadvertent changes for the mods I use?
There are utilities, such as TESPCD, that can be used for this but I understand that many of you are only familiar with the CS so I will limit my discussion to the CS ways only. In the details tab of the CS for the mod, review any references (i.e. ACTI, ARMO, CLOT, etc.) that do not seem to have been placed in the mod by the author using their initials as a naming convention in the ID. You may need to also load MW (and/or Tribunal/Bloodmoon expansions) into the CS only and separately to compare any suspicious references in the mod to see if the ID is a standard reference in MW or the expansions. Be suspicious of any lower-case only IDs or IDs ending with two numbers in the mod being checked. HELPFUL HINT ON A TYPICAL EASY WAY TO FIND THESE IN THE FUTURE USING THE CS: 1) Open up the CS but do not load the mod to be checked, 2) Go to the Files|Data Files menu option in the CS, highlight the mod and select the Details button (do NOT load the mod by selecting OK), 3) Click twice (NOT a double-click, wait a second between each click) on the ID header in the window that has appeared – this will place all ID types (ACTI, ALCH, etc.) in their own section descending by date the ID was created in that section. The standard MW items that have been inadvertently changed will be at the end of each section if they are present in the mod so these are the ones that should be cleaned/reviewed for cleaning (not applicable to REFR section since they should never be cleaned). This may not work for mods that were created prior to the expansions being released IF the mod subsequently added the expansion as a parent master, but if that is the case, the inadvertently changed standard items still should be clumped together somewhere in each section. It may also not work if a utility that adds or deletes parent masters OR reorders the internal date creation field structures was used on the mod, but that should be a rare occurrence.

If the helpful hint in the previous paragraph did not work for me, how else can I tell if a change is inadvertent or intentional by the modder?
This can be the hardest part – determining what to fix. That is why it is always better if the modder cleans the mod of these unintentional changes prior to releasing the mod rather than relying on or expecting users, some of whom may have never opened the CS, to find them for the modder. Obviously, if it is your mod, you know what you intentionally changed. If you are just a user of the mod though it becomes more difficult. Clues are often found in the ReadMe and download page comments by the author. If there is no mention of changing a particular reference, it probably is an inadvertent change if that changed reference is unrelated to the premise of the mod.

How can these inadvertent changes be fixed/cleaned?
You should back up the mod before attempting this! You can fix these standard MW items by toggling them as ignore in the Details tab of the CS (for the Mod A’s inadvertent changes) and then loading and saving the mod in the CS. To bring up the detail tab, open up the CS without loading a mod. You will find the details tab by selecting the File|Data Files menu option. After highlighting the mod to fix, select the Details button (do NOT select the OK button). Find the item to fix in the window that appears, highlight it and press the Delete key on your keyboard. A message will pop up that asks if you want to ignore this reference and say OK to that message. Once you have fixed all the inadvertent reference changes in the Details tab, close the details tab and then select that mod as the active file using the Active button, and NOW select the OK button to load the mod into the CS. Once the mod is loaded (say Yes or Yes to All [Cancel button if Morrowind.ini allows YestoAll] to any warnings that may appear), select the File|Save menu option in the CS. Then select the File|Exit menu option to close the CS. The inadvertent changes have now been removed from the mod. Be sure to now check the saved mod for "evil" GMST changes if the expansions are not parent masters to the newly saved mod.

Can I mess up the playability of the mod by cleaning it for these standard references?
Sadly, the answer is yes. IF the modder made an inadvertent change to a particular standard MW reference causing it to appear as other than a REFR item in the Details tab, AND the modder also placed some of that same item in the game intentionally as part of their mod, fixing the standard MW reference as outlined in the previous paragraph will remove all the intentional placements of that item in the mod. The correct procedure in that case is to first make a backup copy of the mod and then copy down all occurences of that standard MW reference as shown by the Info tab once loaded into the CS, clean the standard MW references as in the previous paragraph and then MANUALLY add back in those items that were removed by the cleaning - check the Info tab in the CS for the item after cleaning to determine the ones that have been removed and now search those Cells and Containers to add the item back in. Very labor-intensive. If you don't do it though, you may be presented at some future date with problems similar to those shown in the three examples above that will be even harder to track down and correct in order to restore stability to your game.

- Rougetet

This post has been edited by Rougetet: Mar 27 2008, 08:50 AM

Moderator: Quoted posts deleted.

I do have a couple of questions about this. I've noticed in my mod that I have CELL references marked as being changed... yet I've never loaded or touched many (if any) of those cells - do I toggle "Ignore" on these? Or will it remove them entirely from the game? Also, I'm assuming that you don't remove temporary references?

I tried my hand at this a couple of days ago after your comment on my mod, and I went and removed the reference "in_v_small_dj" which is a standard MW object. HOWEVER, when I saved and loaded up my mod, I checked in a cell where I used them - and NONE were there! What does that mean?

Could you be more specific on the types that you are able to ignore (like ACT, ARMO etc.) because I don't want to ignore all these references to find that it screws up my mod, so I have to revert to the backup, and then when I upload it, someone says "Oh, you haven't removed the dirty references!"

I think (although I've never used it) ticking Ignore in the CS ignores all changes AND all references to that object in your mod.

Using an external program will only delete changes made to that object, leaving the references intact.

I'm not familiar with the original poster, but cleaning a mod should be standard practice before release. I go one step further and clean my WIP's as I go. I work until I reach a natural break, clean the mod, and increment the version. This way, I can tell early on if I have a problem. I also know that each new version was clean when I started. For example, I'm working on a house mod right now that is up to version 29b. That means I've cleaned it 29 times. The 'b' means I wanted to try out something I wasn't sure I was going to like, and then decided to keep it.

When I am done, every new object should be prefixed with the mod's initials. While I haven't released any of my mods yet, I use them with my own saved games and don't want them mucking them up. I still remember one mod that screwed up the great shell in Ald-ruhn, causing all the doors to float in mid-air. It was next to impossible to get around in there - since some doors were outside of the static. I believe the mod handled door locking, but it was pretty clear that they moved the shell in the mod, and saved it that way. What was bad was that the mod was primarily scripts - there were almost no new, or modified, statics. If I didn't know how to use the CS, and TESAME, that would have put an end to that mod for me.

It may be harsh to point it out, but it doesn't take THAT long to load up TESAME and clean a mod, particularly if you have a naming system or prefix you can use to isolate dirt.

If you are positive that you did not make any changes to those cells or items in them, it is best practice to remove these inadvertent CELL changes from your mod. Leaving them in increases load time slightly - may not seem like too much of an issue for your mod, but if all mods leave them in it adds up. Anytime you give the MW Game Engine more to do that is unnecessary, you are increasing the opportunities for the Game Engine to potentially "hiccup" resulting in a "dirty" save. You should fix any inadvertent item changes (ACTI, ARMO, etc.) BEFORE saving deleted CELL references though in case those CELL references are only being presented because you have inadvertent item changes that happen to be in those cells. As for trying to toggle as Ignore any REFR items in the Details tab, I don't think that the CS will even allow that. Leave REFR items alone.


The problem I believe you are describing is because of the difference between inadvertent and intentional changes in your mod. You INTENDED to add "in_v_small_dj" to certain CELLs BUT you INADVERTENTLY changed some part about it doing so (most likely because you pressed the SAVE button after you made some changes to the Reference Data - select the close window button [little "X" in upper right of open object window] AFTER making your Reference Data changes, and do NOT select the SAVE button after you make them - even though no "real" changes occurred by selecting the SAVE button in this case, the Game Engine and CS will think that there are thus potentially setting up the condition that your mod will reset to MW defaults the "in_v_small_dj" item - any mod loaded before yours that really wanted to change "in_v_small_dj" will now have its changes for that item removed). If you had used the close window button, the STAT "in_v_small_dj" would not have appeared in the Details tab BUT because you added "in_v_small_dj" into a CELL that will appear as a REFR line instead - the correct practice. When you deleted the "in_v_small_dj" STAT line, you also removed it from the CELLs you put it in for this case - at that point, the CS thought that you were removing all changes to "in_v_small_dj" made by your mod. Important to understand the distinction between INADVERTENT and INTENTIONAL changes and how to make an INTENTIONAL change.


Well the quick answer is you want to remove them all (that you didn't create with your own ID) unless you are intentionally changing the standard MW reference as part of your mod. If you truly want to make non-Reference Data changes to an item (attaching a script, changing weight and/or value/enchantment for your implementation of that item but not all items of that type), do so by creating your own ID for the item. At the end of the day, and for other than CELLs/NPCs, a mod that ONLY has IDs you created and NO standard MW references listed AND plenty of REFR lines in the Details tab is what you are looking for (and of course the TES/3 line - although I have seen some mods delete that line without causing any immediate problems, it is best practice to leave it in). REFR lines are for the most part a good thing. They indicate that you have taken a standard MW reference or item you created and done something with it in your mod without changing the original ID (for standard MW items). REFR are what allows the game engine to determine where to put those items in the game for your intended mod changes. It is also good practice to check all IDs you added to a mod to make sure that you have used the item at least once or you know you will add that item through a script and/or dialogue (Count Column row for your added ID > 0). Although it should not directly affect stability by leaving new IDs in your mod that you haven't used or intend to use by adding it with a script, it indirectly affects it because now you have given the Game Engine more to do upon Initial Load (it loads that item into memory anyway in case it needs to refer to it because of a script/dialogue reference - this would require References Persist on the item for it to be useable).

- Rougetet

This post has been edited by Rougetet: Mar 26 2008, 06:45 AM

Clicking Cancel has the same effect as clicking the cross.

Thanks Pixie, although hadn't ever done it that way I am sure you are right.

- Rougetet

Guilty as charged.

Save just seems like the right button to click ya'know?

Anyways, thank you. I learned something for once.

Umm, regardless of what any of you think of how Rougetet has handled himself on other site's rating systems or elsewhere, none of this has anything to do with this thread. *Reported*

Rougetet, thank you for posting this thread, I think that fundamentals such as this should be brought up and discussed every once in a while, especially during times like we've had lately where a lot of new modders are getting involved.

I'm going to throw all discussion of the OP's rating system out of this thread and advise everyone concerned to take the debate offline or to PES.

The OP offered a great deal of good advice, and every one of us needs to be objective enough to grant him that. I am going to leave that advice posted, and the only posts on topic for the remainder of this thread will be those that discuss the need to follow that advice.

We don't do mod ratings on these forums. PES does support a system of mod ratings. So if you want to discuss the OP's system for rating mods, the best place to discuss it is on the forum where the votes are made, within the restrictions the moderators there place on it.

Okay... I managed to read through all of that. However, how can I go and remove the STAT "in_v_small_dj" now, without having to revert back to an earlier version? I realise where I went wrong, but now how can I solve my little wrong-doing?

I shall be going and removing these references from my mods now, most specifically Isaac's House, after this advice. And I'll be making sure I NEVER press the save button on standard MW objects. I think I'll also recommend this topic to some fellow modders, I think this is very valuable information... I almost feel like looking through the details of other mods to see how bad they are!

Thanks for this topic, Rougetet!

The easiest to use & best tool for this is Enchanteded Editor. Just load your mod, click on statics & find the listing for "in_v_small_dj" check that box & hit delete. If you've not intentionally changed any of the game setting GMST entries then GMST should not be bold in EE. This screen shot shows how easy it is. The checked boxes are for the dirty reference you've heard about by clicking the x's underlined in red on the screen shot & saving these will be deleted from my WIP. You can easily identify which cells are dirty by clicking the cell name on the list. A dirty cell will only have an entry for NAME, DATA, and possibly RGNN.

This post has been edited by Nicholiathan: Mar 26 2008, 04:44 PM

After I posted my answer to your other questions, I went back and edited my original post # 1 in this thread to add in another question and answer that specifically answers your quote above (the last paragraph that starts with the question: "Can I mess up the playability of the mod by cleaning it for these standard references?"). You should follow that procedure if you wish to do it in the CS. There may be other programs such as EE and Wyre Mash that may have easier solutions to this but I am not familiar enough with them to comment on how you could use them to assist you with cleaning your specific problem. When I refer to the Info tab in the CS, I am refering to the window that will appear when you load your mod in the CS and right-click on a particular reference object to bring up a window that one of the options is to open an Info tab that will show you wherever the object is used in both the parent masters for your mod AND your mod.

I had taken you at your word that there is a standard MW STAT called "in_v_small_dj" when I had been answering your previous questions, however when I loaded MW and both expansions to look at how many times that object is used in the standard game and/or expansions to help answer this question, I could not find that object as a standard MW reference (even though the way it is named sure looks like the way other standard MW objects are named). Are you sure this is not a specific ID you created for your mod? If it is, we have been chasing a "red herring" and you should not clean it BUT it would be helpful for other users of your mod if in the future you would adopt a best practice naming convention for new IDs you create (precede them with your initials or mnemonic initials for your mod). I looked in the Activator, Door and Static tabs of standard MW with expansions just to be sure but couldn't find that reference listed in any of those. HELPFUL HINT: In the future if you want to do a quick check if a certain ID is a standard MW or expansion ID, open up the CS and ONLY load MW and both expansions (if you have them - DON"T load your mod). Go to the Edit|Find Text menu option of the CS. In the window that appears, select the "Objects, etc" tab and then key in the full ID name in the Search Text field and then select the button that says "Find Text". If nothing appears then it is not a standard MW reference.

- Rougetet

I agree, cleaning out dirty references is a must, though I use TESTool for that task myself, as it's even easier than the Enchanted Editor.

There is an in_velothismall_dj_01 but not to my knowledge an in_v_small_dj as a standard Morrowind static peice. It sounds like someone must have renamed one in a mod or made their own unique doorjamb named that way.

I think a year has passed since I last did any TES projects. The program rules make sense, but in spite, I remember saving a number of unchanged static pieces in a fog. This does not translate between my own characters. Thanks for the fixes and rules. I will try to be more considerate of my own work, even though this is not a mod.

Just had a EUREKA! moment and discovered a very easy way to identify the inadvertent changes made in a mod. I have updated the original post # 1 to add this as a helpful hint. See the rest of the paragraph after the yellow bolded words I added in post # 1.



- Rougetet